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v'"Sk  Discussions  at  a  technical  workshop  on  coabat  casualty  care  held  in  1976 
indicated  that  the  current  method  of  processing  nodical  data  at  the  forward 
echelons  of  treatment  were  inadequate  and  it  was  suggested  that  autoeated 
aethods  be  developed.  Subsequent  workshops  have  identified  specific  func- 
tioaal  snhanceaents  which  could  be  integrated  into  an  autoaated  system  for 
coabat  casualty  care.x 


OBJECTIVE 

^ hhvelop  the  conceptual  design  of  an  autoaated  systea  that  would  aeet 
coabat  casualty  care  inforaation  aanageaent  requireaents  to  aaintain  a  coabat 
aedical  history,  perfora  patient  tracking  and  logging  functions,  and  facili¬ 
tate  the  continuity  of  casualty  care.  - — £»  e.*-^  t>t>i ^ 


APPROACH 

A  systea  prototype  was  developed  as  a  plat fora  for  testing  program  fea¬ 
tures,  functions,  and  design  concepts.  Following  a  typical  coabat  scenario, 
each  of  the  systea' s  capabilities  were  exercised  and  evaluated. 


RESULTS 

This  report  describes  the  Coabat  Casualty  Care  Medical  Inforaation  Systea 
prototype  in  terns  of  hardware,  software,  and  various  functions  which  are  per- 
formed  during  the  operation  of  a  field  aedical  company. 


The  successful  demonstration  of  the  prototype  provides  strong  evidence 
that  a  functional  field  aedical  data  processing  system  can  evercoae  short¬ 
comings  of  the  currant  systea  and  increase  the  productivity  of  aedical 
personnel  by  reducing  their  edninlstratlve  burden.  Potential  systea  eahaace- 
nants  to  the  proposed  operational  systea  ace  also  described  sad  discussed. 
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BACKGROUND 


Automation  of  combat  casualty  care  data  was  a  topic  of  discussion  at  the 
Technical  Workshop  on  Combat  Casualty  Care  hosted  by  the  Naval  Medical  Research 
and  Development  Command  in  April  1976. 1  This  meeting  was  followed  by  a  Fleet 
Marine  Force  Medical  Information  Systems  Requirements  Definition  Workshop  spon¬ 
sored  by  Headquarters,  U.S.  Marine  Corps  (MED)  and  the  Naval  Medical  Research  and 

o 

Development  Command  in  May  1982.  During  these  workshops,  needs  such  as  the 
following  were  identified: 

The  need  to  maintain  complete  and  accurate  medical  records  in  the  field. 

-  The  need  for  medical  history  information  at  forward  echelons  of  medical 
care. 

-  The  need  to  communicate  treatment  information  quickly  and  accurately  along 
the  evacuation  chain. 

The  need  to  rapidly  determine  the  deployability  status  of  Marine  Corps 
personnel. 

As  a  result  of  the  requirements  identified,  the  Commandant  of  the  Marine 
Corps  requested  that  "research,  development,  test  and  evaluation  necessary  to 
produce  an  initial  operating  capability  in  support  of  the  Marine  Corps  be  ini¬ 
tiated.3" 

The  Naval  Health  Research  Center  (NHRC)  began  such  a  program  by  hosting  a 

H 

conference  on  the  Fleet  Marine  Force  Combat  Casualty  Care  Information  System  . 

During  this  conference,  an  alternative  to  the  Field  Medical  Card  (DD  1380)  was 

proposed  and  a  combat  medical  record  was  defined.  From  information  obtained  at 

this  conference,  system  concepts  for  the  Operational  Medical  Information  System 

r  6  7  8  q 

(OMIS)  were  developed.  *  *  *  *  Basically,  it  was  concluded  that  a  casualty  care 
system  would  be  organized  around  a  microcomputer  or  a  network  of  microcomputers  at 
the  third  echelon  of  care  (the  Medical  Company).  Further,  the  system  would  have 
to  operate  within  the  context  of  related  systems  such  as  the  Theater  Army  Medical 
Management  Information  System  (TAMMIS),  the  Composite  Health  Care  System  (CHCS), 
and  the  Shipboard  Non-Tactical  ADP  Program  (SNAP).  Therefore,  it  was  suggested 
that  a  modular  design  be  used,  that  the  system  be  dictionary  driven,  and  that  the 
method  for  transferring  data  among  service  points  be  standardized. 
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To  further  develop  the  conceptual  design  of  the  Combat  Casualty  Care  Medical 
Information  System  (CCC/MIS),  work  began  on  a  system  prototype.  The  objective  of 
this  effort  was  to  address  deficiencies  identified  In  the  previous  workshops,  such 
as: 

-  Field  medical  data  was  frequently  lost  or  not  recorded. 

-  Communication  of  casualty  Information  between  echelons  was  Inadequate. 
Inaccurate  or  Incomplete  reporting  of  casualty  Information  occurred. 

-  Material  inventory  and  replenishment  methods  were  cumbersome  and  Incom¬ 
plete. 

-  Management  reports  were  delayed  and  often  Inaccurate. 

-  The  manual  data  collection  system  was  not  responsive  in  the  time  and  scale 
required. 

This  paper  describes  the  prototype  system  In  terms  of  the  hardware  configuration, 
software,  and  functions  performed.  The  problems  encountered  during  ln-house 
testing  are  Identified,  and  future  plans  for  enhancements  designed  to  resolve 
problem  areas  are  discussed. 

SYSTEMS  ANALYSIS: 

In  an  effort  to  determine  the  detailed  specifications  needed  for  the  proto¬ 
type,  NHRC  conducted  a  rigorous  systems  analysis  of  data  riows  and  communication 
procedures  used  In  training  exercises  by  Marine  Corps  Medical  Personnel  at  Camp 
Pendleton,  CA*°  Initially,  a  questionnaire  was  used  by  team  members  as  a  guide 
for  determining  the  types  of  information  required  at  each  treatment  location 
within  the  Medical  Company.  Once  a  basic  knowledge  was  gained,  team  members 
revisited  various  key  personnel  to  further  Isolate  data  types  and  transmission 
modes.  After  several  visits,  data  flow  diagrams  were  drafted  to  portray  the 
current  procedures  (current  physical  model).  Figure  1  is  a  result  of  the  systems 
analysis  and  clearly  shows  the  complexity  of  the  system  now  In  use. 

From  the  systems  analysis  It  was  determined  that  two  types  of  data  were  being 
processed  at  the  Medical  Company:  1)  medical  (e.g.  Injury  and  treatment  Informa¬ 
tion);  and  2)  administrative  (e.g.  patient  location  and  resource  usage).  It  was 
observed  that  In  many  cases  redundant  and/or  non-essential  data  collection  was 
causing  personnel  to  expend  more  time  and  effort  than  necessary  to  accomplish  the 
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INFORMATION  FLOWS  IN  THE  MEDICAL  COMPANY 


requirements,  and  finally  It  was  obvious  that  the  hand  processing  used  In  the 
current  system  was  time  and  labor  Intensive.  The  structured  analysis  at  Camp 
Pendleton  showed  that  at  least  two  people  are  needed  at  the  Patient  Affairs  Center 
to  record  and  transmit  data,  as  well  as  maintain  the  various  status  boards.  At 
each  of  the  approximately  16  treatment  or  processing  areas,  at  least  one  person 
must  be  responsible  for  log  books  and  data  keeping  materials.  Each  time  a  patient 
enters  any  location  or  changes  status,  a  hand-kept  record  must  be  made  noting 
time,  date,  patient  name,  and  other  Identifying  Information,  as  well  as  the  status 
of  the  patient.  On  the  average,  this  accounts  for  about  a  minute  or  two  of 
processing  time  per  patient  per  log  entry.  For  a  patient  following  a  typical 
routine  of  TRIAGE-ANS-XRAY-PREOP-O.R.-R.R.-Ward  with  the  associated  lab  work,  the 
accumulated  administrative  processing  time  over  a  typical  stay  would  be  about  30 
minutes  per  patient.  For  a  100-bed  facility  over  a  l-M  day  period,  this  could 
result  In  more  than  50  man  hours  being  taken  for  administrative  processing  time  In 
addition  to  the  two  persons  In  Patient  Affairs  and  the  runners  carrying  verbal  and 
hand-delivered  messages.  Therefore,  there  Is  the  equivalent  of  about  3-1/2 
medical  personnel  who  are  unavailable  for  medical  care  because  of  their  adminis¬ 
trative  duties. 

Based  on  the  estimated  time  savings,  an  administrative  module  was  determined 
to  be  an  essential  component  of  CCC/MIS.  A  computerized  administrative  module 
would  perform  such  functions  as  the  logging  In  and  out  of  patients  to  the  various 
treatment  locations  and  use  the  data  to  provide  status  board  reports. 

CONFIGURATION  POR  IN-HOUSE  TEST 

To  emulate  the  medical  company  environment,  four  office  spaces  at  NHRC  were 
used.  The  two  mo3t  distant  rooms  were  approximately  100  feet  apart.  One  large 
room  was  used  to  represent  Admitting  and  Sorting,  along  with  Triage.  Another 
large  room  across  the  hall  was  the  location  of  surgery  and  the  wards.  One  small 
room  represented  Patient  Affalrs-Medlcal  Operations  Center  while  another  small 
room  represented  the  laboratories  (see  figure  2). 
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Hardware :  The  rooms  representing  the  Medical  Company  were  linked  with 

computer  cabling  to  allow  for  the  use  of  a  Local  Area  Network  (LAN)  to  provide 
sharing  of  the  following  resources: 

o  four  IBM-compatible  microcomputers 

-  each  having  640  KB  RAM 

-  two  with  two  standard  5-1/4"  floppy  disk  drives 

-  two  with  bubble  memory  boards  (1/2  MB) 

-  one  containing  a  20  MB  hard  disk  and  one  standard 
5-1/4"  floppy  disk  drive 

-  one  with  a  5  MB  removable  hard  disk  and  one  standard 
5-1/4"  floppy  disk  drive 

o  two  data  key  reader/writers  with  datakeys 
o  one  graphics  digitizer  tablet 
o  four  small  two-line  bar  code  terminals 

System  Software:  For  the  initial  software  development,  DBase  III  was  used 
for  data  storage  and  report  generation  because  of  its  utility  as  a  rapid  prototype 
development  tool.  However,  the  interfaces  with  the  peripheral  devices  (data  key, 
digitizer  tablet,  and  bar  code  terminals)  were  written  in  Turbo  Pascal. 

Additional  software  and  modifications  were  necessary  for  the  LAN  to  function. 
This  network  provided  the  means  by  which  data  collected  at  any  treatment  location 
could  be  shared  by  any  of  the  four  computer  locations. 

FUNCTIONAL  DESIGN 

The  medical  and  administrative  functions  performed  by  the  prototype  CCC/MIS 
are  as  follows: 

o  Patient  registration 
o  Tlme/date/locatlon  logging 
o  Medical  information  input  and  storage 
o  Generation  of  spot  status  reports 
o  Patient  discharge. 

Each  of  these  functions  are  described  below. 
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Patient  Registration  and  Discharge:  Every  service  person  Is  currently 
required  to  wear  Identification  tags  (dog  tags)  which  contain  personal  as  well  as 
medical  Information.  To  demonstrate  alternative  methods  of  data  storage  and 
entry,  a  device  (datakey)  similar  In  size  to  a  standard  Identification  tag  was 
carried  by  each  casualty  and  used  to  store  personal  and  medical  Information 
electronically.  During  patient  registration  the  Datakey  belonging  to  the  simu¬ 
lated  casualty  was  placed  Into  a  reader  (located  in  the  triage  area)  In  response 
to  a  computer  screen  prompt.  Data  from  the  key  wa3  then  merged  with  a  computer 
generated  Identification  number  time  and  date  of  registration  and  triage  informa¬ 
tion  supplied  by  the  staff  person.  At  this  point  the  information  was  stored  In  a 
database  available  for  general  use  by  anyone  in  the  system.  The  following  shows 
the  computer  prompts  given  to  the  staff  person  in  charge  of  patient  registration: 


REGISTRATION  MENU  PROMPT: 

Step  1: 

COMBAT  CASUALTY  CARE  MEDICAL  INFORMATION  SYSTEM 
TRIAGE  AND  DISCHARGE  STATION 

INDICATE  IF  PATIENT  IS  ENTERING  OR  LEAVING?  (IN  OR  OUT) 


(System  waits  for  user  input.  If  input  Is  "IN",  the  computer  prompts  for  triage 
category  after  assignment  of  a  patient  number. ) 


Step  2: 


COMBAT  CASUALTY  CARE  MEDICAL  INFORMATION  SYSTEM 
TRIAGE  AND  DISCHARGE  STATION 


THIS  PATIENT  HAS  BEEN  ASSIGNED  ID  NUMBER 
28 

PLEASE  INPUT  THE  TRIAGE  CATEGORY  (l,2,3,i»)  FOR  THIS  PATIENT 
DOES  THIS  PATIENT  HAVE  A  DATATAG?  (1-YES,  O-NO) _ 


(After  triage  category  Is  entered,  the  user  Is  asked  about  the  patient's  datatag. 
If  the  patient  does  have  a  datatag,  he  will  be  registered  and  the  system  will 
return  to  the  first  menu  prompt.  If  patient  does  not  have  a  data  tag  one  can  be 
generated  at  that  time.) 
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During  the  prototype  demonstration  a  patient  can  only  be  discharged  from  the 
triage  area.  When  a  patient  is  discharged,  'OUT'  is  entered  in  Step  1.  As  a 
result  the  following  prompts  are  given  to  the  staff  person: 

DISCHARGE  MENU  PROMPTS 

Step  1:  (System  starts  here  and  waits  for  input.) 

COMBAT  CASUALTY  CARE  MEDICAL  INFORMATION  SYSTEM 
TRIAGE  AND  DISCHARGE  STATION 

INDICATE  IF  PATIENT  IS  ENTERING  OR  LEAVING 1  (IN  OR  OUT) _ 


(Because  patient  is  checking  out,  user  Is  asked  for  patient's  ID  then 
disposition. ) 


Step  2: 


PLEASE  INPUT  THE  PATIENT  ID  NUMBER. _ 

PLEASE  INPUT  PATIENT  DISPOSITION  (RTD  OR  EVAC) 


(After  Input  of  patient  ID  and  disposition,  the  full  patient  identification  is 


displayed ) 

PATIENT  NAME 

SSN 

TRIAGE 

DOB 

WILSON 

333-33-3333 

3 

03/03/63 

PATIENT  NUMBER  23 
IS  CHECKING  OUT  AT 
12:55:04 
09/20/86 
FOR  EVAC 

(The  system  then  returns  to  the  first  menu  prompt.) 

It  should  be  noted  that  at  each  data  entry  point  the  staff  person  has  the  option 
of  using  a  keyboard  entry,  a  bar  code  pen,  or  datakey  as  appropriate.  These 
options  speed  up  data  entry  as  well  as  greatly  reducing  the  chance  of  error. 


Medical  Information:  To  again  demonstrate  the  utility  of  alternate  data 
Input  mechanisms,  a  proposed  replacement  for  the  Field  Medical  Card  (DD1380)  was 
used  to  represent  combat  casualty  data  supplied  by  a  corpsman.  This  form,  printed 
on  mylar.  Is  virtually  lndestructable  and  makes  use  of  body  charts  and  checklists 
to  record  Injuries  and  treatments  (see  figure  3). 

A  Graphics  Digitizer  Tablet  Is  used  as  the  data  input  device  for  this 
Information.  This  Is  an  automated  input  device  which  Is  programmed  using  grid 
coordinates  to  accept  specific  data  when  contact  is  made  at  specific  locations  on 
the  tablet  with  a  stylus.  The  form  is  placed  on  the  tablet  into  pre-set  location 
pins  and  the  stylus  (a  pen-type  device)  is  used  to  point  to  the  body  parts  which 
have  been  wounded  and  treated.  Touching  the  marked  points  sends  a  coded  message 
to  the  attached  computer  where  the  data  is  decoded  and  stored  for  future  refer¬ 
ence.  A  simple  menu  prompt  Is  displayed  on  the  computer  screen  for  the  user  to 
follow.  This  procedure  is  very  simple,  making  it  possible  to  use  non-medical 
personnel  such  as  walking  wounded  to  operate  it.  After  the  data  from  this  form  Is 
entered  into  the  computer,  the  form  can  be  kept  in  the  patient's  medical  folder 
along  with  other  documents. 

Log  Functional  It  was  observed  during  the  systems  analysis  that  virtually 
every  treatment  location  within  the  medical  company  required  a  log  entry  for  each 
patient.  Making  these  entries  is  often  disruptive,  time  consuming,  and  frustra¬ 
ting,  since  much  of  the  information  Is  redundant  and  of  dubious  accuracy.  Each 
log  entry,  besides  Identifying  the  patient,  requires  time,  date,  location,  and 
possibly  additional  data.  On  the  average,  the  logging  procedure  takes  one  or  two 
minutes  per  patient  per  location,  which  can  consume  many  hours  per  day  when 
dealing  with  close  to  a  hundred  patients. 

During  the  prototype  demonstration,  the  logging  functions  were  handled 
through  the  use  of  bar  codes  and  bar  code  readers.  Bar  coded  labels  containing  a 
unique  patient  number  were  applied  to  patient  wrist  bands  upon  entry  to  the 
simulated  medical  company  when  the  patient  was  registered.  A  bar  coded  response 
pad  was  also  located  at  each  logging  area  (see  figure  4).  Every  time  a  patient 
changed  location,  the  wrist  band  was  read  with  a  bar  code  reader,  and  when 
appropriate  additional  Information  was  prompted  for  by  the  small  bar  code  terml- 
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nala  located  at  each  treatment  area.  This  logging  process  generally  did  not  take 
more  than  15  to  20  seconds.  The  patient  Identification  number,  after  being  passed 
to  the  computer,  was  supplemented  with  computer  generated  time,  date  and  location 
and  stored  In  a  generally  accessible  data  base. 

Spot  Status  Reports:  The  Patient  Affairs  Center  Is  the  information  center 
for  the  Medical  Company  and  Is  the  place  where  all  of  the  Spot  Status  Reports  are 
generated.  During  the  demonstration,  updated  reports  were  generated  by  computer 
in  roughly  5  minute  Intervals  and  required  no  human  intervention  or  monitoring. 
As  each  report  was  generated  It  was  placed  on  the  computer  screen  for  a  minute  or 
so  in  a  continuous  flow.  The  spot  status  reports  demonstrated  were: 
o  Patients  currently  In  treatment 
o  Patients  previously  discharged 
o  Blood  use  and  availability  (shown  below) 
o  Current  patient  locations 

o  Number  of  patients  regsltered  each  of  the  last  4  days 
o  Bedtypes  available  and  In  use  (shown  below) 

TYPICAL  SPOT  STATUS  REPORTS 

BLOOD  STATUS  REPORT: 


BLOODTYPE 

ONHAND 

INITIAL 

RECEIVED 

USED 

EXPECTED 

A+ 

100 

100 

0 

0 

0 

A- 

100 

100 

0 

0 

0 

AB+ 

100 

100 

0 

0 

0 

AB- 

100 

100 

0 

0 

0 

B+ 

97 

100 

0 

3 

0 

B- 

100 

100 

0 

0 

0 

0+ 

100 

100 

0 

0 

0 

0- 

200 

200 

0 

0 

0 

PLASMA 

500 

500 

0 

0 

0 
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BED  STATUS  RE  PORT : 


BEDTiTPE 

AVA ILABLE 

COUNT 

AMB 

24 

1 

KIA 

20 

0 

MIM 

50 

0 

NBC 

1 

0 

OPG 

10 

0 

SBN 

20 

0 

SCI 

5 

0 

SGS 

73 

2 

SMF 

5 

0 

SNS 

5 

0 

SOP 

5 

0 

SOR 

5 

0 

STH 

SUR 

5 

10 

0 

CONCLUSION: 

The  prototype  demonstration  showed  that  automation  of  medical  and  administra¬ 
tive  functions  has  the  potential  of  greatly  reducing  the  administrative  burden  on 
medical  personnel  during  combat  situations.  Because  of  the  structuring  of  certain 
types  of  data  gathering  processes,  accuracy  can  be  increased  and  non-medical 
personnel  such  as  the  walking  wounded  can  be  used  as  data  entry  personnel. 
Furthermore,  once  the  data  Is  stored  in  an  electronic  database,  status  reports 
documenting  patient  flows  which  are  difficult  to  compile  manually  can  be  readily 
generated. 

Although  the  software  and  hardware  were  successfully  Integrated  and  the 
various  functions  were  demonstated,  the  demonstration  did  reveal  areas  of  the 
system  that  should  be  improved  prior  to  a  field  test.  In  the  area  of  hardware, 

i 

the  Bar  Code  Terminal  devices  proved  to  be  the  most  troublesome  piece  of  equip¬ 
ment,  These  required  an  inordinant  amount  of  special  programming  to  become 
Integrated  into  the  system.  The  IBM  compatible  computers  which  were  used  posed 
another  hardware  problem.  They  frequently  failed  and  the  manufacturer's  support 
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for  this  equipment  was  less  than  adequate.  In  the  area  of  software,  DBase  III  Is 
a  proprietary  database  management  package  with  limited  device  handling  capability. 
Finally,  It  could  not  be  determined  whether  It  was  the  hardware  or  the  software 
aspect  of  the  LAN  that  made  It  difficult  to  work  with.  However,  other  more 
well-behaved  systems  are  available. 

FUTURE  EFFORTS 

Future  efforts  will  be  directed  toward  the  resolution  of  the  problem  areas 
Identified  and  the  development  of  a  system  suitable  for  testing  In  a  field 
environment.  To  resolve  the  hardware  problems,  the  Bar  Code  Terminals  will  be 
replaced  with  hand-held  microcomputers  with  a  built-in  bar  code  reader.  The 
existing  computers  will  be  replaced.  A  new  software  environment  will  be  explored 
In  which  VA  Fllemanager  software,  a  government-developed  database  management 
package,  will  be  used  for  database  management.  With  regard  to  problems  with  the 
LAN,  two  solutions  will  be  pursued.  First,  a  new,  more  sophisticated  network  will 
be  tested.  This  has  the  advantage  of  hardware  redundancy.  Thus,  If  one  micro¬ 
computer  malfunctions,  operations  can  continue  on  the  other  three.  However,  the 
additional  overhead  of  network  boards,  software,  and  cabling  leads  to  the  consi¬ 
deration  of  the  second  solution,  a  multi-user  system  configuration.  This  confi¬ 
guration  will  be  based  upon  a  host  computer  which  maintains  a  central  database  and 
ultimately  controls  all  peripheral  devices.  A  system  such  as  the  one  In  figure  5 
1 s  potentially  easier  to  maintain  and,  if  a  Journalling  capability  can  be  deve¬ 
loped,  may  prove  to  be  sufficiently  reliable  to  be  the  host  for  the  CCC/MIS. 

In  addition  to  resolving  problems  Identified  during  ln-house  testing,  CCC/MIS 
will  be  enhanced  In  a  variety  of  ways  prior  to  field  testing.  First,  the  outputs 
will  be  expanded.  For  example,  current  status  reports  will  contain  more  types  of 
Information  and  new  status  reports  will  be  developed.  A  printer  will  be  used  to 
output  these  reports  In  a  hard-copy  format.  In  addition,  the  potential  use  or 
mouse  systems,  touch  screens,  and  voice  recognition  devices  will  be  evaluated. 
Also,  various  output  devices  such  as  voice  synthesizers  will  be  tested.  Depending 
upon  the  results,  these  devices  may  be  included  in  the  planned  field  test. 
Finally,  a  digital  communication  capability  betwen  the  Medical  Company  system  and 
rear  echelons  will  be  incorporated  Into  CCC/MIS. 
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